With the rapid development of Internet, data service is becoming the mainstream of network services. How to efficiently transmit data service while guaranteeing the conventional Time Division Multiplex (TDM) service transmission is a major challenge to telecommunication operators. The Generic Framing Procedure (GFP) technology can encapsulate protocol data units (PDUs) into GFP frames efficiently and transmit them on the network, which makes it possible for telecommunication operators to build an advanced, flexible and strong new-generation Multi-Service Transmission Platform (MSTP) network.
The GFP is defined in ITU-T recommendation G.7041/Y.1303 or in ANSI standards. This framing procedure can be applied to both the encapsulation of entire client frames (frame mapped GFP), in which a single client frame is mapped into a single GFP frame, and to character mapped transport (transparent GFP), in which a number of client data characters are mapped into efficient block codes for transport within a GFP frame.
The format for GFP frames is shown in FIG. 1. GFP frames are octet-aligned and consist of a GFP core header 11 and, except for GFP Idle frames, a GFP payload area 12. The four octets of the GFP core header 11 consist of a 16-bit PDU length indicator field 13 and a 16-bit core Header Error Check (cHEC) field 14. The two-octet core Header Error Check field 14 contains a CRC-16 error control sequence that protects the integrity of the contents of the core header 11 by enabling both single-bit error correction and multi-bit error detection. The GFP payload area 12 consists of two common components: a payload header 15 and a payload information field 16. An optional payload Frame Check Sequence (pFCS) field 17 is also supported.
The GFP payload header 15 contains two mandatory fields, the type field 151 and the type Header Error Check (tHEC) field 152, and a variable number of additional payload header fields. This group of additional payload header fields is referred to as the extension header 153. The presence of the extension header, and its format, and the presence of the optional pFCS are specified by the type field 151.
The type field 151 is a mandatory two-octet field of the payload header that indicates the content and format of the GFP payload information field. The type field distinguishes between GFP frame types and between different services in a multi-service environment. The type field consists of a Payload Type Identifier (PTI), a Payload FCS Indicator (PFI), an Extension Header Identifier (EXI) and a User Payload Identifier (UPI). The two-octet type Header Error Check (tHEC) field 152 contains a CRC-16 error control sequence that protects the integrity of the contents of the type field and tHEC field by enabling both single-bit error correction and multi-bit error detection.
Three kinds of extension headers are currently defined, a null extension header (EXI=0000), a linear extension header (EXI=0001), and a ring extension header (EXI=0010) for further study. When the Extension Header Identifier (EXI) shows that the type of the extension header is a linear frame mode for instance, the extension header field 153 consists of a CID field and a Spare field. The CID is an 8-bit binary number used to indicate one of 256 communication channels at a GFP termination point and the 8-bit Spare field is reserved for future use.
The two-octet extension Header Error Check (eHEC) field 154 contains a CRC-16 error control sequence that protects the integrity of the contents of the extension header field and eHEC field by enabling both single-bit error correction and multi-bit error detection.
The payload information field 16 contains the framed PDU for frame mapped GFP or, in the case of transparent GFP, a group of client signal characters. This variable length field may include from 0 to 65536-X octets, where X is the size of the payload header. This field may include an optional pFCS field 17.
The pFCS is an optional, 4-octet long, frame check sequence. It contains a CRC-32 sequence that protects the contents of the GFP payload information field 16. The pFCS is generated using the CRC-32 generating polynomial (ISO/IEC 3309) G(X)=X32+X26+X23+X22+X16+X12+X11+X10+X8+X7+X5+X4+X2+X+1, where X32 corresponds to the Most Significant Bit (MSB), and 1 corresponds to the Least Significant Bit (LSB).
Data in a GFP frame shall be scrambled before transmitting. In general, the core header 11 is scrambled for DC balanced by an exclusive-OR operation (modulo-2 addition) with the hexadecimal number “B6AB31E0”. Whereas all octets in the payload area 12 are scrambled using an X43+1 self-synchronous scrambler.
FIG. 2 illustrates the scrambler and descrambler of GFP payload area 12. The descrambler has an error multiplication factor (EMF=2), and every bit error is transformed into two bit errors, the original one and the consequential one, which is 43-bit space apart from the original one and is named as the additional error bit.
In the prior arts, the solution of processing a GFP frame cannot compensate the impact of payload area descrambler error multiplication factor. Thus, it is a great disadvantage that the prior arts cannot correct the additional single-bit error and cannot avoid the loss frame or error frame due to the additional error bit.